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1.  INTRODUCTION 


The  biith  of  supercomputers  aod  massively  parallel  [»xx:essing  machines  affords  researchers  and 
scientists  the  computer  power  lu  simulate  real  world-class  problems  defined  by  huge  grids.  As  a  result 
of  this,  huge  amounts  of  output  data  are  gerrerated;  thereby  creating  a  need  for  post-processing  software 
capable  of  handling  and  evaluating  such  huge  dau  sets. 

This  report  will  describe  a  parallel  method  of  computing  isosurfaces  of  a  tiivariate  function,  F(x,y  js), 
described  by  a  variation  of  the  unformatted  PLOT3D  file  format  This  output  consists  of  three-sided 
polygons  defining  a  surface  where  F(x,y,z)  is  some  constaru  value.  The  format  for  the  outimt  file  will  be 
a  generic  polygonal  format  called  Bag-O-Polygons  (Bop).  The  purpose  of  a  parallel  version  of  die 
marching  cubes  method  is  to  allow  processing  of  huge  data  sets  which  cannot  be  read  totally  into  a 
machine’s  memory.  This  marching  cubes  implementation  is  cr^iable  of  computing  isosurfaces  of  any  size 
grid,  whether  it  be  regularly  or  irregularly  spaced.  This  implementation  relies  on  slicing  the  grid  in  the 
k  direction,  and  therefore,  would  require  the  regular  or  irregular  grid  to  be  oriented  in  such  a  manner  to 
accommodate  this  method.  The  C  routines  referenced  in  this  report  are  capable  of  executing  on  the 
Silicon  Graphics,  Inc.  workstations.  Sun  workstations,  and  the  Kendall  Square  Research  1  machine.  The 
multiple  platform  parallel  execution  is  made  possible  through  the  use  of  sproc,  fork,  and  pthreads.  Timing 
results  from  the  three  platforms  will  be  given  in  section  4  of  this  report 

2.  MARCHING  CUBES  METHOD 

Marching  cubes  is  a  high-resolution,  three-dimensional  (3D)  surface  construction  algorithm  written 
by  Lorenson  and  Cline  (1987).  The  marching  cubes  method  is  the  means  by  which  one  defines  a  3D 
surface  of  a  constant  value,  S  =  F(x,y,z),  from  some  vcdume  of  data  represented  by  a  structured  grid 
(Figure  1).  The  term  marching  comes  horn  the  notion  that  oik  marches  through  the  volume  of  data  a 
cube  at  a  time.  A  cube  being  a  six-sided  polygon  defiiKd  by  eight  nodes  and  two  adjacem  plaiKs  in  each 
direction  of  i,j,  and  k. 

The  algoritiun  marches  through  each  cube  determining  whether  the  intoided  surface  intersects  any 
edges  of  the  cube.  The  intersections  are  deteimiiKd  by  placing  a  zero  or  a  oik  at  each  of  the  eight  iKxles. 
A  one  is  assigned  to  a  cube's  node  (vertex)  if  the  data,  S,  at  that  node  is  greater  than  or  equal  to  the  user- 
specified  value.  Otherwise,  a  zero  is  placed  at  the  node  if  S  falls  below  Ok  user-specified  value.  Uring 
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this  combination  of  zeros  and  ones,  <ui  8-bit  number  is  constructed.  The  8-bit  number  is  an  index  into 

a 

a  table  containing  2  possible  combinations  of  topologies  for  a  surface  defined  within  a  given  cube 
(Rgure  2).  Although  there  are  256  possiUe  cases  defining  surface  mtersections  with  the  edges; 
through  symmetry  operations  and  complementary  cases,  the  problem  can  be  reduced  to  15  major  cases. 
Figure  3  shows  the  15  major  cases  which  consist  of  0-4  triangles  per  cube. 
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k; 


Rgure  3.  15  case  configuration 

After  retrieving  tfie  triangulation  for  a  specific  cube  from  the  table,  linear  interpolation  is  used  to 
determine  where  die  vertices  of  the  triangle(s)  will  intersea  with  the  edges  of  the  cube.  Thus,  forming 
a  list  of  three-sided  polygons  defining  the  connectivity  of  the  isosurface. 

3.  PARALLEL  IMPLEMENTATION 

The  parallel  implementation  of  the  marching  cubes  algoridim,  written  in  C.  nms  on  Silicon  Grt^cs, 
Inc.  (SGI)  Workstations  under  IRIX,*  on  Sun  Workstations  under  SunOS,**  and  on  the  KSRl  (Kendall 
Square  Research  1)  under  KSR  OS,***  which  are  all  UNIX****-compatible. 

3.1  Incut  Data  ReouiremenL  The  parallel  marching  cubes  code  requires  a  variation  of  the  C 
unformatted  PLOT3D  grid  and  solution  files.  More  specifically,  the  parallel  isosurface  generator  roiuests 
the  irqnit  data  in  two  separate  PLOT3D  multiple  grid,  3D  whole,  xyz,  and  Q  (without  Jacottian)  file 
formats. 


I  and  IRIX  are  trademaria  of  Silicon  Gnqjhka,  be. 

**  1  and  SunOS  are  (radonailci  of  Sim  Microayitema. 

:  »SR1  and  KSR  OS  are  tredeniaria  of  Kendall  Square  Reaearch  Coiporation. 
**  UNIX  is  a  tredemaik  of  Bell  Laboniorics. 
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Although  the  multiple  grid  foimat  is  used,  the  code  expects  the  number  of  grids  to  equal  one.  Also, 
the  Q  file,  otherwise  referred  to  as  the  "solution  file,"  is  not  limited  to  five  ^cific  scalar  and  vector 
components,  as  specified  in  the  PLOT3D  User’s  Manual  (1989).  The  user  wiU  need  at  least  one  scalar 
defined  in  the  solution  file  to  complete  a  successful  execution.  In  the  case  of  one  scalar,  the  user  can 
define  an  isosurface  of  a  constant  value  of  that  scalar,  S,  and  map  the  identical  scalar  onto  the  surface  for 
color  mtq)ping  purposes.  In  instances  when  there  are  more  than  one  scalar  in  the  solution  file  die  user 
has  the  flexibiliQ^  to  pick  and  choose  any  scalars  for  defining  the  isosurfaces  and  the  isosurface  mapping. 
See  Appendix  A  for  the  description  of  the  C  syntax  for  writing  this  variation  of  the  unformatted  PLOT3D 
grid  and  solution  files. 

Additional  input  is  required  from  the  command  line.  The  command  line  arguments  will  specify  the 
PLOT3D  grid,  Plot3D  solution,  and  Bop  filenames  for  argv[l]  dirough  argv[3],  respectively.  The  user 
should  also  supply  the  numeric  index  into  the  Q_file  indicating  which  scalars,  and  S^,  will  define 
the  isosuiface  and  isosurface  mapping,  aigv[4]  and  argv[5];  a  floating-point  isosuiface  value.  aigv[6]:  an 
integer  value  specifying  the  number  of  planes  to  step  in  the  k  direction,  aigv[7];  and  finally,  an  integer 
value  indicating  the  number  of  processes  to  spread  the  problem  across,  aigv[8].  See  Appendix  B  for  an 
example  shell  script  for  executing  this  parallel  isosurface  generator  using  the  above  command  line 
arguments. 

3.2  Distribution  of  Woridoad.  The  parallel  implementation  consists  of  multiple  routines;  some 
routines  are  controlled  by  the  parent  process,  while  others  are  implemented  by  the  childrea  The  parent 
process  controls  the  initial  opening  of  the  files  to  retrieve  header  information  from  both  die  grid  and 
solution  files.  Once  the  number  of  grids  (one)  and  dimensions  in  i,  j,  and  k  are  read  in,  the  parent  calls 
the  routine  to  partition  the  processing  of  the  isosurface  using  the  slice  strategy.  This  partitioning  routine 
creates  a  C  structure  containing  the  information  eadi  child  requires  in  order  to  determine  which  part  of 
the  grid  it  will  read  and  process.  Having  formed  the  partitioning  structure,  the  parent  produces  children 
totaling  the  number  ^cified  by  the  cotrunand  line  argument,  argv[8].  The  parent  creates  new  processes 
using /crk  or  sproc  on  the  SGI  workstations,  on  the  Sun  workstations,  and  pthreads  on  die  KSRl 
machine.  These  new  processes  (children)  are  responsible  for  calculating  polygons  defining  the  isosurface, 
and  writing  the  corresponding  data  to  the  Bop  file.  Due  to  the  nature  of  the  marching  cubes  problem, 
each  child  process  may  or  may  not  be  required  to  perform  output  operations.  Therefore,  children  widi 
small  or  no  output  will  complete  execution  before  those  children  widi  larger  output  requirements. 
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3.2.1  Fork.  Fork  is  a  standard  UNIX  call  for  creating  a  new  process.  This  new  process,  known  as 
the  "child  process",  is  an  exact  copy  of  die  calling  process  (parent  process).  During  a  normal  fork,  the 
writable  portions  of  the  process’s  address  space  are  marked  copy-on-write.  Hence,  if  any  process  writes 
onto  a  given  page,  a  copy  of  that  page  is  created  and  given  to  that  process.  Writes  by  one  process  are 
not  visible  to  the  other  existing  processes  including  the  parent  process  (calling  process).  Although  the 
child  process  is  an  exact  copy  of  the  parent  process,  the  child  has  a  unique  process  id  (pid),  a  different 
parent  process  ID,  and  has  its  own  copy  of  the  parent’s  file  descriptors. 

3.2.2  Sproc.  Sproc  is  a  SGI,  IRIX  specific  routine  which  creates  a  new  share  group  process.  While 
sproc  is  a  variant  of  the  standard  UNIX  fork  call,  inherent  differences  between  the  two  exist  When  a 
parent  or  child  calls  sproc,  a  new  process  is  created.  Instead  of  the  new  process  being  an  exact  copy  of 
the  parent  as  in  fork,  the  child  shares  the  virtual  address  space  (shared  memory,  mrqiped  flies,  and  data 
space)  of  the  parent  process.  This  is.  of  course,  assuming  that  one  has  selected  the  sharing  option.  In  the 
case  of  sproc,  the  parent  and  child  each  have  their  own  stack  pointer  and  program  counter,  but  all  the  data 
and  text  space  is  visible  by  both  processes.  After  a  successful  sproc,  the  parent  and  child  process  wiU 
have  unique  pids,  but  are  in  the  same  shared  process  group. 

The  first  time  sproc  is  called,  a  share  group  or  shared  process  group  is  formed.  AU  subsequent  calls 
to  sproc,  whether  it  be  by  the  parent  or  child,  will  add  another  process  to  the  share  group.  As  mentioned 
above,  all  members  of  the  share  group,  share  virtual  address  space,  as  well  as  possible  sharing  of  file 
tables,  effective  userids,  current  working  directories,  and  other  options  which  may  be  specified  by  the  m/i 
flag  of  sproc. 

3.2.3  Pleads.  The  KSR  pthread  is  a  high-level  interface  to  the  IEEE  POSIX  thread  library  (IEEE 
1990).  KSR  Cp£Area</(POSIX  threads)  functions  are  called  to  create  and  synchronize  processes.  Pdtread 
objects  are  made  up  of  pthreads  themselves,  mutexes,  condition  variables,  and  barriers.  Variables 
accessible  to  one  pdiread  are  available  to  all  other  pthreads  in  that  process.  Multiple  threaded  processes 
operate  in  a  single,  shared  address  space.  Due  to  the  sharing  of  address  space,  creating  pthreads  incurs 
considerably  less  overhead  than  creating  a  new  process.  In  general,  multi-threaded  processes  share  most 
of  their  data,  but  often  use  private  variables  for  thread  operations. 

Pthreads  use  the  qualifiers,  _private  and  shared,  to  specify  whether  a  declared  variable  will  be 
pthread-private  or  shared.  In  declaring  a  variable  pthread-private,  each  pthread  has  a  private  copy  of  that 
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variable.  AH  variables  not  declared  private  are  shared;  therefore,  the  qualifier  jhared  is  never  required. 
Default  private  variables,  such  as  automatic  and  register  variables  cannot  be  declared  shared. 


3.3  Data  Output  Fbrmat  Although  there  are  many  output  fonnats  which  can  be  defined  for  a  large 
variation  of  commercial  graphics  packages,  this  parallel  isosurface  generator  ouqxits  the  Bop  foimat  The 
Bop  format  can  be  easily  written  and  netwoiked  with  the  use  of  the  Bop  libraries.  These  libraries  have 
been  linked  with  the  parallel  isosurface  code  to  allow  the  polygonal  data  to  be  writtoi  to  disk  files  or 
netwoiked  across  heterogeneous  architectures  using  BopJ/iew  (daike  1993). 

Since  diis  parallel  isosurface  generator  utilizes  the  slice  strategy  for  implementing  parallelism,  some, 
if  not  all  of  the  child  processes  could  very  well  arrive  at  the  function  responsible  for  writing  polygons  in 
the  Bop  format,  simultaneously.  To  prevem  such  collisions,  semaphores  have  been  employed  to  allow 
only  one  child  to  write  or  netwoik  polygons  in  the  Bop  fonnat  at  a  time. 

Upon  completimt  of  the  isosurfaoe  generation,  the  Bop  fonnat  in  conjunction  widi  BopJ^iew  saves 
images  from  the  viewport  in  a  number  of  file  formats.  These  files  can  later  be  used  to  create  3D  video 
animations  or  color  hardcopies.  Refer  to  the  Bop  and  Bop_View  documentation  (Claike  1993)  for  a 
complete  description  and  examples  for  using  this  file  format  and  application. 

3.3.1  Bop  Fonnat  The  Bop  format  is  a  binary,  polygonal  format  This  format  contains  the 
information  necessary  for  Bop^View  to  visualize  the  list  of  polygons  defining  the  isosurface.  Each 
polygon  is  defined  by  a  C  structure,  bpo/y,  whose  members  include:  an  integer  specifying  foe  number 
of  vertices  and  the  floating-pomt  values  for  x,  y,  z,  and  the  mapping  scalar  for  each  vertex  of  foe  polygoa 
The  libbopui  library  contains  the  functions  required  for  opening,  writing  to,  and  closing  Bop  files. 

It  is  also  important  to  note  that  the  Florida  State  University  and  the  Supercomputer  Research  Institute’s 
public  domain  scientific  visualizatioo  and  animatiai  package,  SciAn,  has  a  Bqp  file  reader. 

3.3.2  Bop_View.  This  is  an  X-window,  Motif  tqjplication  program  for  visualizing  pcdygonal  data. 
Bop_yiew’s  X-window  viewport  is  capable  of  rendering  polygons  to  an  X-window,  with  foe  cqxion  of 
rendering  these  polygons  in  foe  SGI  Gnqfoics  Language  (GL).  Once  the  polygons  have  been  rendered 
in  foe  viewport,  foe  user  can  use  combinations  of  x,  y,  z  translations,  rotations,  and  scaling  to  mient  foe 
isosurface  to  a  desirable  location  and  size.  The  user  has  foe  choice  of  writiitg  the  polygons  in  SGI’s  igb 
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(red  green  blue),  BRL.CAD’s  pix,  or  PostScript’s  file  foimaL  The  UMopjnrsui  library  oxitains  the 
functions  required  for  opoiing  and  sending  polygonal  information  via  a  TCP/IP  connection  to  a  Bop_yiew 
process  locally  or  remotely. 

4.  RESULTS 

The  parallel  implementation  of  the  marching  cubes  algorithm  has  been  used  to  generate  isosur<'  es 
of  computational  data  horn  the  CTH  and  HULL  codes,  as  well  as  medical  resonance  data.  All  thrt 
output  formats  were  converted  to  a  variation  of  tire  PLOnr3D  grid  and  solution  file  formats,  as  mentioired 
earlier. 

Prior  to  the  development  of  this  parallel  isosurface  generator,  a  3D  volume  of  computational  data  of 
-2.2  M  floating-point  grid  values  and  -11  M  floating-point  scalar  values  required  a  walldock  time  of 
-20  min  per  time-step  to  read  the  entire  grid  and  associated  scalars  into  memory,  calculate  the  desired 
isosurface  of  -60  thousand  polygons,  write  the  polygons  to  an  X-window,  and  dump  die  viewport  of  the 
X-window  into  an  image  file.  Using  die  same  dataset  while  processing  the  isosurface  widi  the  parallel 
isosurface  generator,  writing  polygons  via  MRS  to  Bop_yiew,  and  generating  an  image  file  takes  -90  s. 

Figures  4-6  represent  timing  results  of  isosurface  generation  using  the  parallel  implementation  on  die 
SUN4m  spare,  SGI  Challenge,  and  KSRl  machirres.  Timings  are  based  on  an  eight  processor  maximum 
for  the  SGI  and  the  KSRl,  and  two  processors  for  the  SUN4  spare.  All  timings  include  total  execuden 
time,  which  indudes  the  time  for  input  and  ouqiuL  Therefore,  timing  differences  between  die  KSRl  and 
the  SGI  and  SUN4m  platforms  are  considerably  different  due  to  iiqmt/ouqiut  contingendes  tm  the  KSRl. 
The  timing  results  are  given  to  simply  show  differem  test  cases  and  are  not  being  used  as  an  evaluation 
of  any  of  die  spedfic  architectures. 

5.  CONCLUSIONS 

Huge  datasets,  whether  they  be  on  the  order  of  millions  or  billitms  of  points,  can  be  poA  processed 
with  this  parallel  isosurface  generator,  given  that  at  least  two  slices  (mardiing  in  die  k-direction)  can  fit 
into  a  machine’s  idiysical  memory.  This  piecewise  calculation  has  been  tested  on  SUN4,  SGI,  and  KSRl 
machines,  yielding  results  not  possitde  using  other  commerdal  and  public  domain  packages  t^ch  assume 
that  one’s  volume  of  data  will  fit  entirdy  into  a  machine’s  memory. 
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Figure  5.  Time  vs.  number  of  i 


Plot  for  SGI 


Linking  this  parallel  isosurface  generator  with  a  givm  computation  code  can  yield  a  machine- 
indepoKlent  means  for  creating  interactive  graphics.  The  combination  of  the  piecewise  isosurfaoe 
computatitm  and  the  X-window  display  via  TCP/IP  using  Bop^View,  makes  for  a  flexible  envinmment  for 
producing  interactive  visualization.  This  capability  is  a  useful  tool  for  analyzing  and  debugging  3D 
volumetric  data. 


8 


•  4  •  •  r 

Nuntotr  of  Proe»M4 


INTEOTIONALLY  LEFT  BLANK. 


10 


6.  REFERENCES 


Claike.  J.  "Distributed  Heterogeneous  Visualization:  Bop  miJBop-View.”  U.S.  Anny  Research 
Laboratory,  Aberdeen  Proving  Ground.  MD.  to  be  published. 

Lorensen,  W.  E..  and  H.  E.  dine.  "Marching  Cubes:  A  High  Resolution  3D  Surface  Constructkm 
Algorithm."  SIGGRAPH  87  Conference  Proceedings,  Computer  Graphics,  vol.  21,  no.  4. 
pp.  163-169,  July  1987. 

NASA  Ames  Research  Center.  PLOT3D  User’s  Manual.  Moffett  Field,  CA,  1989. 

Institute  of  Electrical  and  Electronics  Engineers.  Threads  Extension  for  Portable  Operating  Systems. 
(P1003.4a).  p.  10.  1989. 


11 


INTEIWONALLY  LEFT  BLANK. 


12 


APPENDIX  A: 

UNFORMATTED  PLOT3D  VARIATION  OF  THE  GRID  AND  SOLUTION  FILES 
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A.  Unformatted  PLOT3D  Variation  Of  The  Grid  And  Solution  Ffles 


/*  This  Function  Reads  A  Generic  Data  File  And  Writes  Two  Files  Which  Are 
A  Variation  Of  The  PLX)T3D  Khiltiple  Grid  (3D  Whole,  XYZ)  And  Q  (Without 
Jacobian)  File  Formats.  */ 

#include  <sldio.h> 
void 

var  plot3d(dur  **aigv) 

{ 

int  ngrids  -  0; 

int  idim  >  0,  jdim  -  0,  kdim  -  0; 

int  nunt_vetts  -  0; 

int  i  ••  0; 

int  (Hocjd  -  1; 

int  num^orks  -  2; 

int  fotk_num  -•  0; 

int  status  -  0; 

int  chiid[2]  -  {0,  0}; 

float  X  -  0.0,  y  -  0.0,  z  -  0.0; 

float  w  -  0.0,  tha  -  0.0,  iho  -  0.0,  pres  -  0.0; 

float  •vx  -  NULL,  *yy  -  NULL,  ‘vz  -  NULL; 

float  *vw  -  NULL,  •vrha  -  NUIX,  *vtho  -  NULL,  ‘vpies  -  NULL; 

float  8calat(4]  -  {0,  0,  0,  0}; 

FILE  'input  -  NULL,  'grid  -  NULL,  'sol  -  NULL; 


/*  Open  Input  And  Output  Files  Given  From  The  Command  Line.  */ 

input  -  fopen(atgv[ll,V'); 
grid  -  fopen(argvt2i,"w"); 
sol  -  fopen(aigvI3),'V"); 


/*  Grab  Dimension  In  The  I,  J,  and  K  Direction  From  the  Command  Line.  */ 

idim  -  atoi(argv[4]); 
jdim  -  atoi(argv[5]); 
kdim  •>  atoi(argv[6]); 

ngrids  -  1; 

num_vetts  ••  idim  *  jdim  *  kdim; 


/*  Allocate  Memory  For  Grid  And  Solution  Variables.  */ 

ifi((vx  -  (float  *  )cailoc(nuiii_veitS4izeof(float)))  — >  NULL){ 
fjprintf(etdeir,'XJnable  To  Calloc  vx.Vi"): 
perrot("Calloc 
exil(-l); 

} 

if((vy  -  (float  *)canoc(nuiit_vertSAizeof(float)))  »  NULL){ 
^>iintfi(stdeiT,"Unable  To  Calloc  vy.Nn"); 
penoi("C^oc 
exit(-l); 

} 

if((vz  -  (float  *)calloc(nnmL.vetts4izeof(float)))  —  NULL){ 
4nintfi(stdetr,"UnabIe  To  Calloc  vz.Nn”); 


|MiM)i("Cdloc 

ejuK-l); 

> 


if((vw  -  (float  •  )calloc(iniRt_veitSAizeof(fk>tt)))  —  NULL){ 
fpnnt^stderr.'Unable  To  Calloc  vw><i”); 
penoi<"Calloc 
exil(-l); 

} 

if((viha  -  (float  *)calloc(nun\_veitS4i2Mf(fk>at)))  —  NIJLL){ 
fprintffst^iT,  "Unable  To  Calloc  vifaa.\n'V< 
peinn<"Calloc 
exit(-l); 

} 

if((viho  -  (float  *)calloc(nuii\_vetts,atxeof(float)))  —  NULL){ 
fprintflst^iT, "Unable  To  Calloc  vtfao.Sn'V, 
penw<"Calloc 
ekit(-l); 

} 

if((vpees  -  (float  *)calloc(nunt_vetta4izeof(float)))  —  NULL){ 
fprinlf(stdeiT, "Unable  To  Calloc  vpies.'^'O; 
perror("Calloc 
exit(-l); 

} 


/*  Read  Data  From  A  Generic  Data  File.  */ 

for(i-0;i<nuin_veits;i++){ 
facanf(input,"%f  %f  %(",  Ax,  Ay,  Az); 
fscanf(input,“%f  %f‘.  Aw,  Atha); 
facanf(input,"%f  %f',  Aitio,  Apies); 

vxp]  -  x; 
vyp]  -  y; 
vx[i]  -  x; 

vwp]  -  w; 
viha{i]  -  rtia; 

vrhon]  “  rfto; 

vpiesp]  -  pres; 

} 


/*  Fork  Two  Processes,  One  Will  Be  Used  To  Create  The  Grid,  And  The  Otiter  For 
The  Solution.  */ 

foi(i^,  knum_foiks;  i++){ 
foA.num  -  i; 

if(proc_id!-0){ 
proc.id  -  ftnkO; 

} 

else{ 

bleak; 

} 

if{pioc_kl  —  -1){ 
penoKToffc"); 

fpriiitf(stdeiT.''ERROR  -  CAN  NOT  FORK  FROCESS.V); 
exit(-l); 
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-1  */ 


}  /*  end  if  ptoc.is  — 
elM  if<proc_id  —  0){ 
if(fotk.jium  —  0){ 
fwiite(Angrids.sizeof(int),  1  .grid); 
fwrite<&idiin.si7«)f(int),  1  .grid); 
fwrile(&jdini,sizeof(int),  1  .grid); 
fwrite(Akdiiii,sizeof(int),  1  .grid); 
fwrite(vx.sizeof(f]oat)Auiq_vetts.grid); 
fwrite(vy.8izr9f(fk>at)Auiq_veits.grid); 
fwrite(vz.sizeof(float).nunuveils.grid); 
child[forii:^num]  -  getpidO; 

printf("cfaild[9E)d]  -  {socess  conqdetedNi"Jotfc^tun.child[fotk_num]); 
}  /•  end  if  foik_nuin  —  0  */ 
if(foTk_num  •—  1){ 
fwrile(&ngrids.sizeof(int).  1  .sol); 
fwiite(&idini.sizeof(int).  1  ;sol); 
fwrite(&jdin).si2eof(int).  1  .sol); 
fwrite(&kdiin.sizeo^int).  1  .sol); 
fwrite(scalaT.sizeof(flo«t).4.sol); 
fwrite(vw.sizeof(floal)jiun)L.verts4ol); 
fwrite(viha.sizeofi(flost)4iun\_verts.sol); 
f«vrite(viho.sizeof(float).num_veits.sol); 
fwrite(vpies.sizeof(float)4iuin^veils.sol); 
child[foik_num]  -  getpidO; 

printf("child[%d]  -  process  con^detedNi".forit_|iuni.child{foik_num]); 
}  /*  end  if  fork_num  —  1  */ 

}  /•  end  if  proc_id  —  0  •/ 

}  /*  end  for  i  •/ 

I*  Have  Parent  Process  Wail  Until  The  Children  Have  Completed.  */ 

for(i-0;i<nun]Lforics;i++)'{ 

wait(&status); 

} 

if(proc_id  !-0){ 
exit(nunx_foria); 

} 

} 


17 


Intentionally  left  blank. 


18 


APPENDIX  B: 

PARRALLEL  ISOSURFACE  GENERATOR  SHELL  SCRIPT 
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B.  Parrallel  Isosurface  Generator  Shell  Script 


#!  /hin/csh  -f 

#  This  shell  scr4)t  executes  PBIG  with  the  following  perameten: 

#  Gnd  File  Name:  /usi/tii^i/KlNifke/bdf02.gnd 

#  Solution  File  Name:  /usi/tinp/Kbaiie/hdflaMl 

#  BOP  File  Name:  /ttsi/tnifi/Kbuike/bopl 

#  ScLmuh-iao.data  -  2 

#  ScLtiuin_i<to_niap  -  1 

#  Isovalue  -  S.O 

#  Kstep  -  3 

#  Num_pn>cs  -  $1 

« 

#  Note:  User  dmuld  set  Kstep  equal  to  2  or  3 

« 

ifl$l  — -  '’)then 

echo  "Usage:  $0  Numjnocs" 

exit  (1) 

else 

set  DDIRWusiftnip/Kbaike 
set  GRID>hdi02 
set  SOU4Mli02 
endif 

rm  -r  SDDIRl/bopl 

echo  "Executing  /usi/tinp/ICbuike/PBIG" 

/usi/tmi«1Cbuike/PBIG  SDDIRl/SGRID.grid  SDDIRl/SSOL^I  SDDlRl/bopl  2  1  5.0  3  $1 
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